[レポート] ExcelからIDEへ、そしてその先へ〜データエンジニアの原点と未来 #dbtCoalesce

大阪オフィスの玉井です。

2022年10月17日〜21日に行われたCoalesce 2022というハイブリッド（オンライン+オフライン）カンファレンスが開催されました。主催はdbt labs社です。

本記事は、その中で発表されたFrom Excel to IDE and beyond: The origins and future of the data developerというセッションについて、レポートをお届け致します。

セッション概要

登壇者

• Katie Hindson
  • Head of Product & Data, Lightdash

超概要

最近のデータ分析に関するツールやサービスは、コードを書いたりそれらをバージョン管理したりと、ソフトウェア開発っぽくなってきています。

そんな中で、現在のデータパイプラインの開発現場には様々な問題がありますが、それらを解決するのにも、ソフトウェア開発のベストプラクティスを参考にするのが良い話です。

セッションレポート

前段

Katieと申します。Lightdashの責任者をしています。もう10年近くデータ分析の仕事をしています。この間、さまざまなことが変化してきました。しかし、変わらないものもあります。そして、それはそろそろ変わるべき時期だと思っています。

この10年でデータアナリストの技術力は格段に上がったと思います。しかし、私たちの（データ分析の）開発ワークフローは、それを反映していません。データアナリストやアナリティクスエンジニアは、もうExcelやTableauで仕事をしているわけではありません。GitHub、VScode、CUI、BigQueryで作業しています。

私たちは、よりソフトウェアエンジニアに近い形で開発を進めていますが、開発ワークフローはそれに追いついていません。

そこで、より良いものとはどのようなものか、私が考えていることをお話しします。そして、私が考える変革の可能性について、いくつかの例を挙げながらお話ししたいと思います。

ここ10年間でのデータ分析基盤の変化

本題に入る前に、この10年間でデータ分析基盤がどのように変化したのか、少し背景を説明します。また、「データ分析の開発」とはどういうことかを説明します。

2012年に戻ってきたと想像してみてください。そこでは、Amazon Redshiftが登場したのです。そして、超並列処理と呼ばれるもので、データウェアハウスに革命を起こしました。

Redshiftが登場する前の問題はスピードで、データをロードする前に転送する必要がありました。しかし、今ではそれが問題ではなくなりました。そのため、この分野では新製品が爆発的に増えました。

そして、Redshiftの後の5年間には、StitchやFivetranなどのデータ抽出ツール、dbtなどのデータ変換ツール、LookerやMetabaseなどのBIツールなどが登場しました。

基本的にデータエンジニアでない人でも管理できるデータスタックができました。つまり、ある程度の経験を積んだデータアナリストを雇えば、データスタック全体を完全に管理できるようになったのです。

これらの新しいツールは、データチームがこれまで以上に技術的に強くなることを意味します。

データアナリストの仕事内容は、コマンドラインの使い方、GitHubの使い方、クラウド型のIDEの使い方などを知っていることが期待されるようになったのです。そして、バージョン管理され、テストされ、文書化されたデータセットの構築と維持に、より注意を払うようになりました。

また、自分たちのために単発の分析を構築するのではなく、ユーザーが自分の質問に答えられるような方法でデータをモデル化するようになりました。そのため、ExcelやTableauを使うことは少なくなりました。そして、GitHubやVScode、BigQuery、コマンドラインなどを使うようになったのです。

このように、私たちは新しいツールを使い続けた結果、米国では新しい役割が誕生することになりました。アナリティクスエンジニアが登場したのです。データチームは、ビジネスアナリストというよりも、データ開発者のような存在になっていました。

さて、私たちはこの素晴らしい革命とすべてのツールを手に入れ、とてもクールになりました。

しかし、いくつかの点で追いつけませんでした。具体的には、新しいエキサイティングなツールやデータパイプラインの統合のことです。

データビルダーである私たちは、多くのツールに力を感じています。それぞれの用途を深く理解し、これらのツールが私たちの生活をとても便利にしてくれるようになる前のことを思い出しています。だから、分析に力を与えてくれるフェラーリエンジンのようなものを手に入れたような気がするんです。

確かに、これらのツールは単体でも素晴らしいものです。しかし、それらを組み合わせたとき、フェラーリというより、スライドにあるような不揃いの車のように見えてしまうのです。だから、このデータパイプラインで開発するのは、ちょっと嫌なのです。

一般的なデータパイプラインの開発プロセス

ここでいうデータ開発とは、このデータパイプラインの中に何かを追加することを指します。例えば、dbtモデルに新しいフィールドを追加したり、モデルのテストを設定したり、BIツールとのやり取りを行ったりします。

このプロセスが破綻しているというのはどういうことなのか、具体的に説明したいと思います。私たちの多くが毎日使っている一般的な開発プロセスの例を紹介します。

簡単に言うと、モデルやフィールドをBIツールに追加して、チャートで使えるようにします。これらの流れを、もう少し詳しく話していきます。

さて、最初のステップは簡単で、新しいモデルをdbtに追加するだけです。VScodeやテキストエディタ、あるいはdbtクラウドを使って、簡単にできます。そして、モデルを構築したら、それをテストするのです。

モデルを実行すると、SQLエラーが発生します。一回目で正しいSQLが書けるようになることは、一生に一度の経験だと思います。ですから、このSQLをデバッグするステップは、少なくとも私にとってはよくあることなのです。

コンパイルしたクエリをdbtのターゲットフォルダから探します。そして、コードをコピーして、BigQueryを開いて、そこにペーストして、SQLをデバッグしようとします。

そして、SQLを正しく実行できるようになったら、その末尾のカンマを削除します。

dbtに戻り、クエリをコピー・ペーストします。そして、ターゲットフォルダにコピー・ペーストしていないことをダブルチェックします。そして、dbtモデルを再実行すると、すべてがスムーズに実行されます。

次のステップは、dbtの実行がうまくいったので、手作業でモデルにドキュメントを追加することに時間を費やします。それから、一意性が保たれているか？とかnullではない？とか、既成概念にとらわれないテストをいくつか追加することに時間をかけます。それが終わると、dbtのテストを実行して、すべてがうまくいくことを確認します。もちろん、何かが失敗します。

BigQueryを開いてテストのデバッグを行い、dbtに更新を加えるというサイクルを繰り返すことになります。このようなことが何度か繰り返され、最終的に解決することができるのです。

これらのことがすべてうまくいくようになったら、いよいよGitHubにモデルをpushします。コードレビューをして、おそらくまたdbtでいくつか変更を加えて、マージしてGitHubにアップします。

しかし、今日、このモデルが必要な理由は、重役から頼まれたダッシュボードを作る必要があり、それを今すぐ行う必要があるからです。ですから、一度変更をマージしたら、Airflowでモデルを再実行する必要があります。私は、私の変更によって影響を受ける私のDAGの部分を手動でトリガーし、すべてが実行されるのを待ちます。

そして、私は私のモデルが実行されるのを待っている間、私はLookerにあった、私のモデルのためのViewを作成します。そして、私が多くの時間をかけて書いたドキュメントとdbtをすべて手作業でLookerに追加しています。そして、いくつかのメトリクスをLookerに追加して、ようやくチャートを作る準備が整いました。

データの実行はすべて順調なので、Lookerに入り、自分のViewにいきます。新しい美しいモデルや追加したばかりのフィールドを使ってチャートを作りましたが、メトリクスとプロットの1つに何か変なことが起きています。LookMLを確認すると、問題なく表示されています。ということは、データモデルに根本的な原因があるのでしょう。

私は目を丸くして、深呼吸をして、潜在的に社内チャットをチェックしに行きます。なぜなら、今、私は自分のパイプラインの一番最初のところに戻って、もう一度すべてのプロセスを始めなければならないからです。これは、データパイプラインの開発において、ほとんどの人が知っていることでしょう。これは「BIツールに新しいものを追加する際の15ステップ」のようなもので、私たちも定期的に行っています。

さて、このワークフローの一番最初のステップは、SQLを書き、それが動作することを確認するという、最も時間を消費するものであるはずです。

しかし実際には、このようなつながりのないアプリの束ができあがり、それらを調整するのに多くの時間と労力が必要になりました。そのため、実際にデータモデルを立ち上げて、他のデータパイプラインで実行するには、必要以上に時間がかかります。データモデルの構築から実際に使用するまで、まるでカオスというか、スパゲッティのような状態です。

一般的なデータパイプラインの開発フローの問題点

さて、昨年から今年にかけて、このことについてよく考えてみました。そして、「これはひどい」と思ったのは自分だけではないはずだと思ったのです。たくさんのツールが至るところにありました。そして、何をするにも時間がかかってしまうのです。

そこで私は多くの時間を費やして、さまざまな会社のさまざまな技術スタックのデータ担当者と話し、彼らのデータ開発の経験について尋ねました。

その結果、ほとんどの人がデータパイプラインにおいて、先ほど説明したのと同じようなレベルのカオスに陥っていることがわかりました。そして皆と話した後、異なる経験に共通する問題を見つけ出そうとしました。その結果、さまざまな問題が見つかりました。

今日はそれらを、3つに絞って話をしようと思います。

データ開発のワークフローから導き出された3つの大きな問題、まず、テスト環境が少ないということです。dbtはこれを実現する数少ないツールの一つですが、それでもBigQueryでSQLの変更を常にテストしなければなりません。もう一つの大きな問題は、なぜマージする前にBIツールで変更をテストできないのか、ということです。なぜ、わざわざ最初に戻らなければならないのでしょうか。

2つ目の問題は、タスクを実行するために多くのツールを切り替えなければならないことです。前回の例で見たように、何かを開発するために少なくとも3つのツールを切り替えなければなりません。なぜなら、それぞれのツールには必要なコンテキストが少しずつ異なるからです。そこで、これらのコンテキストを1カ所に集めてしまえばいいのです。

そして3つ目の問題は、ツール同士で同期が取りにくいということです。dbtにドキュメントを追加したり、LookerやMetabaseにフィールドを追加したりするわけです。また、dbtの変更を本番データセットに取り込み、それをBIツールに追加して同期させようとするだけです。こんなに手作業で、こんなに時間がかかることはないはずです。

データパイプライン開発における問題点を解決する

さて、このセッションの残りの時間は、データパイプラインの開発で直面する問題の多くが、ソフトウェア開発ツールの中で既に解決策を備えている、ということをお話しします。

そして、ソフトウェア開発ツールに大いに触発された解決策を提案することで、私が言いたいことをお見せしようと思っています。

開発時のテスト環境

最初にお話しした問題は、開発時のテスト環境があまりにも少ないということです。

今、ソフトウェア開発では、Netlifyというツールがありますが、これはこの問題を解決する素晴らしい例です。

例えば弊社はLightdashの開発においては、Netlifyのプレビューをジョブにつなげ、ドキュメントに変更を加えるたびにPRを開くと、Netlifyが自動的に開発者プレビュー環境を立ち上げてくれるのです。自分の変更を公開したら、ドキュメントがどうなるかを確認できますし、マージする前に、自分の変更が本番でどうなるかを実際に見ることができるのです。

でも、「Netlifyを使えばそれでOK」というような乱暴なものではいけません。ここからインスピレーションを得て、それをデータ版として応用する必要があります。

今回でいうと、自分の変更がデータパイプラインの下流にどのように影響するかを、マージする前に確認できるようにすべきなのです。例えば、Netlifyのようなものをデータ用に弊社で作りましたが、これは開発者プレビューとかdashプレビューと呼ばれていました。dbtプロジェクトを開発しているディレクトリでlightdash previewを実行すると、Lightdashのようなインスタンスのプレビューが自動的に立ち上がります。dbtに追加したディメンションやメトリクスをテストすることができます。そして、次の段階の変更に進む前に、すべてが意味をなすかどうかを確認します。

つまり、開発者プレビューやdbtからの変更点のテストなど、BIツールでは次のスライドのようになります。

これは素晴らしいことです。このようなテスト環境は、私たちにふさわしいものであり、データ開発はこれを最適化するだけで、私たちが持っている開発経験のようなものです。

ツールの切り替え多すぎ問題

2つ目の問題は、タスクを完了させるために多くのツールを切り替えるということです。

ソフトウェア開発では、問題を解決するために必要なすべてのコンテキストを一つの場所に集約することで、これを解決するツールの例がたくさんあります。

今回はそのうちの一つ、つまりツールの一つであるCentryについてお話しします。Centryは、オープンソースのエラー追跡ツールです。完全なスタックトレースと非同期コンテキストを備えています。基本的には、プロダクション環境のエラーを本当に素早く見つけて修正することができます。

このツールから受ける大きなインスピレーションは、問題を解決するためのコンテキストが一つの場所に集約されていることです。つまり、エラーがあることがわかり、それをクリックすれば、何が問題なのかがわかります。そして、何がエラーになっているのかを知ることができます。

さて、Centryのようなものを作って、dbtのエラーのために、すべてのコンテキストを1つのメッセージに集約することを想像してみてください。

これは、私が想像しているようなものです。というのも、私たちの多くは正直に言って、Slackに多くの時間を費やしているので、こういうものになりまいした。

1は、どのモデルで問題が発生したかという情報と、エラーの深刻さを示すインジケータが表示されます。

2は、ボタンをクリックすると、BigQuery（または使用しているデータウェアハウス）のAirflowをデバッグすることができます。このボタンをクリックすると、BigQueryのクエリエディタが開き、テスト用にコンパイルされたシーケンスが表示されます。これにより、テストが失敗している行を調査することができます。

3は、エラーメッセージが表示されます。どのテストが何回失敗しているかという情報が表示され、これがどの程度重要かを判断するための重要なメタデータとなります。

4は、そのデータモデルを最後に変更した人にタグを付けるというものです。つまり、基本的にエラーに対処する人を自動的に割り当てるのです。これで、ボタンをクリックするだけで、この問題をSlackで直接解決できるようになります。これはとてもクールなことだと思います。

こういうことをしないと、本番のdbtモデルからのエラーのデバッグは、こんな感じになってしまうのです。

私たちはデータ開発において、このようなシンプルさが必要なのです。

ツール間の同期問題

3つ目の問題は、ツール間の同期がとれていないことです。

ソフトウェア開発では、継続的インテグレーションと継続的デプロイメント（CI/CD）と呼ばれるものがあります。CI/CDは、アプリの開発フロー（の一部）を自動化することで、ユーザーにアプリを頻繁に提供する方法です。CircleCIのようなツールを使えば、テストやデプロイを自動で行い、継続的インテグレーションをパイプラインに組み込むことができます。例えば、PRに対して自動的にテストを実行したり、マージされたら全インスタンスにデプロイするようにコードをトリガーしたりすることができます。

では、継続的インテグレーションと継続的デプロイメントが、データ開発のためにあったとしたらどうでしょうか。dbtプロジェクトで何かを変更すると、それが自動的に残りのデータパイプラインに伝搬されると想像してください。

例えば、dbtモデルの変更がBIツールに自動的に同期されたり、ドキュメントが必要なすべてのツールに直ちにプッシュされたり、PRが自動的にテストを実行して、変更が他の統合プラットフォームで何かを破壊しないかをチェックしたりといったことが考えられます。このような例は他にもありますが、これは夢のような状態です。

この夢の状態を少し分解してみると、これらのステップはおそらくGitHub Actionのようなもので、マーケットプレイスで入手して自分のRepoに追加することができるものだと想像されます。

弊社では、この例を実現するために、dbtの変更をLightdashのインスタンスに自動的にデプロイするためのGitHub Actionを実際に作りました。つまり、dbtプロジェクトの更新があれば、それが自動的にpushされ、手動で操作することなくツール間の同期が保たれるのです。さらに GitHub Actionを作成し、PRを開くたびに先程説明したプレビュー環境をデプロイしています。PRをレビューする人がdbtの変更を開き、実際に出力してみることができます。これはすべて自動化されています。

つまり、私たちが行っているテストは、この自動化された統合によって、dbtに実装された変更を実際に見ることができるようになり、より信頼性が高くなったということです。さて、これはとても素晴らしいことだと思いませんか。この種のツールを使ったデータ開発では、そうあるべきなのです。

データパイプライン開発の考え方を変える

さて、ここまでデータチームが直面する3つの問題についてお話ししてきました。そして、これらの問題を実際に解決する方法について、いくつかのアイデアを紹介しました。しかし、これらの情報に対して私たちは何をすべきなのでしょうか？

データパイプラインの開発について、私たちは考え方を変える必要があると思います。

具体的には、データ開発を直線的なプロセスとして考えるのをやめ、各ツール間で情報を受け渡しするだけにする必要があると思います。その代わりに、最適化が必要なシステムとして考える必要があります。

そうすることで、物事を違った角度から考え、自問自答するようになるのです。

例えば、変更を加えるために導入されるタッチポイントやツールはいくつあるのか？また、システム全体で迅速かつ信頼性の高いコラボレーションを行うにはどうすればよいか？また、開発当初から生産に至るまで、どれくらいのスピードで反復作業を行うことができるのか。そして、これらの問題は、私たちがデータ担当者として本当に技術的になって以来、過去10年以上にわたってソフトウェア開発者が直面し、最適化してきた問題と同じものなのです。

ですから、もし私たちがデータ開発を最適化されるべきシステムとして考え始めるなら、同じような問題を解決するために、ソフトウェア開発から多くの類似したアイデアを借りることができます。そして、ソフトウェア開発者が経験するような素晴らしい開発経験を、データチームにも提供したいのです。奇妙な故障車のような状態から、フェラーリを運転するような甘い体験ができるようにしたいのです。私たちは、エンジニアのように開発したいのです。しかし、そのためには、データパイプラインにおける開発についての考え方を変える必要があります。

おわりに

Looker（LookML）やdbtの登場で、にわかにソフトウェアエンジニアっぽくなってきたなあとは思っていましたが、いよいよデータ分析に関わる立場の人は、みんなソフトウェア開発について（ある程度）学ぶべきなのかもしれませんね。